\chapter{Techniki pisania aplikacji internetowych}

Rozdział ten ma na celu przybliżyć najnowsze techniki pisania aplikacji internetowych o
wysokim stopniu reaktywności z użytkownikiem. Aplikacje takie są znane jako bogate aplikacje
internetowe (ang. \emph{Rich Internet Aplication}, \emph{RIA}).

\section{Problem pisania dużych aplikacji internetowych}

Podczas pisania każdej większej aplikacji, programista lub zespół programistów, zostaje postawiony
przed wyborem architektury swojego programu. Dotyczy to każdego rodzaju aplikacji, zarówno serwera
WWW, systemu magazynowego, aplikacji internetowej. Odpowiednia architektura ma zapewnić przejrzysty
podział programu na mniejsze części, które współpracując ze sobą mają wykonywać powierzone aplikacji
zadanie, np. odpowiadanie na żądania HTTP. Szybkie wprowadzanie zamian oraz nowych funkcjonalności do
już istniejącej aplikacji, w jak najkrótszym czasie i nie powodujących regresji w już istniejących
częściach jest jedną z miar sukcesu w procesie tworzenia i poźniejszego działania
oprogramowania.

Aplikacje internetowe stanowią ciekawy przypadek w gronie programów. Ich ostateczna forma to
najczęściej dokument HTML, arkusz stylów CSS oraz kod JavaScript. Niestety stworzenie niewiele
różniącej się strony wymaga jej skopiowania. Jeśli chcielibyśmy wprowadzić zmiany strukturalne,
które są wspólne dla wszystkich stron, musielibyśmy zmieniać każdą po kolei.

Na przestrzeni lat powstały narzędzia umożliwiające, po stronie serwera, generować w locie kod HTML
za pomocą różnej maści języków programowania. Jednymi z najpopularniejszych do tej pory są PHP oraz
JSP. Pozwalają one na użycie dynamicznego kodu (na przykład pobierającego dane z bazy danych) do
wygenerowania kodu HTML, który ostatecznie zostanie przesłany przez serwer WWW do przeglądarki
klienta. Podejście takie ma wielką zasadniczą wadę. Miesza logikę biznesową naszej aplikacji z
prezentacją danych. Na szczęście na ratunek przychodzą dobrze znane architektoniczne wzorce
projektowe.

\subsection{Wzorzec MVC}

\begin{figure}
\centering
\includegraphics[width=0.7\textwidth]{image/pic-mvc-diagram}
\caption{Diagram wzorca MVC}
\end{figure}

Pod rozwinięciem skrótu MVC kryje się pojęcie \emph{Model-Widok-Kontroler} (ang.
\emph{Model-View-Controller}). W ogólnej postaci definiuje on podział aplikacji na części. Definiuje
rolę każdej z nich i opisuje zależności występujące pomiędzy nimi.

\subsubsection{Historia}

Wzorzec stworzył prof. Trygve Reenskaug z Uniwersytetu w Oslo pod koniec lat 70-tych XX wieku, w
czasie swoich wizyt w Xerox PARC (Palo Alto Research Center) \cite{mvc-reenskaug}. W tamtych czasach
rozwój interfejsów użytkownika w aplikacjach nie był tak popularny i ważny jak dzisiaj, ale
założenia wzorca pozostały praktycznie niezmienione.

\subsubsection{Model}

Pod pojęciem \emph{Modelu} rozumiemy obiekty, które są odpowiedzialne za zbieranie i przechowywanie
danych. Często także definiują logikę biznesową aplikacji.

\subsubsection{Widok}

\emph{Widok} (ang. \emph{View}) to sposób prezentacji naszych danych, czyli \emph{Modelu}. Należy
zwrócić tutaj uwagę na fakt, że \emph{Widok} jest zależny od \emph{Modelu}.

\subsubsection{Kontroler}

\emph{Kontroler} (ang. \emph{Controller}) jest czynnikiem łączącym dwa powyższe pojęcia. Podczas
aktywności to \emph{Kontroler} podejmuje odpowiednie decyzje, bazując na akcji użytkownika. Pobiera
\emph{Model} i wybiera odpowiedni dla niego \emph{Widok}.

\subsubsection{Podsumowanie}

Wzorzec ten jest szeroko stosowany w ogromej ilości internetowych szkieletów aplikacji (ang. \emph{Web
Framework}), które posiada niemal każdy liczący się w dzisiejszych czasach język programowania.

\subsection{Wzorzec MVP}

\begin{figure}
	\centering
	\includegraphics[height=0.5\textwidth]{image/pic-mvp-diagram}
	\caption{Diagram wzorca MVP}
\end{figure}

Wzorzec MVP, czyli \emph{Model-Widok-Prezenter} (ang. \emph{Model-View-Presenter}) podobnie jak MVC
pozwala na podział aplikacji na części. Różnią się jednak zależnościami pomiędzy poszczególnymi
częsciami wzorca.

\subsubsection{Historia}

Historia MVP sięga początku lat 90-tych ubiegłego wieku i połączonych prac IBM i Apple nad systemem
Taligent \cite{mvc-fowler}. Nie jest tak popularnym wzorcem jak MVC, ale przyjął się bardzo mocno w
technologii .NET.

\subsubsection{Model}

Rola \emph{Modelu} w tym wzorcu jest praktycznie taka sama jak w przypadku wzorca MVC. Różnice widać w
zadaniach, które mają spełniać \emph{Prezenter} oraz \emph{Widok}.

\subsubsection{Widok}

\emph{Widok} jest całkowicie niezależny od \emph{Modelu}. Nie wie zatem w jaki sposób wyglądają
dane, które ma wyświetlać. W zależności od przyjętej konwencji nie jest także zależny od
\emph{Prezentera}. \emph{Widok} spełnia tutaj zadanie zbioru pól do wprowadzania i wyświetlania
danych. Definiuje także sposób pobierania i wstawiania wartości dla tych pól. Pozwala na ustawianie
zachowania względem akcji użytkownika. Zachowanie to jednak nie jest ustalane bezpośrednio w nim
samym.

\subsubsection{Prezenter}

\emph{Prezenter} spełnia podobną rolę jak \emph{Kontroler} we wzorcu MVC. Pobiera \emph{Model} i
decyduje jak go wyświetlić. Posiada najczęściej instancję \emph{Widoku}, do którego przekazuje dane
z \emph{Modelu} (nie cały \emph{Model}). Zadaniem \emph{Prezentera} jest także definiowanie zachowań
na akcje podejmowane przez użytkownika. Zachowania są przekazywane do \emph{Widoku}, aby ten mógł
odpowiednio reagować.

\subsubsection{Podsumowanie}

Jedną z zalet tego wzorca jest możliwość podmiany \emph{Widoku} i zastąpienia go specjalnie
spreparowanym obiektem (mock) co umożliwia łatwe testy jednostkowe logiki zawartej w
\emph{Prezenterze}. Jednak utrzymywanie \emph{Widoku} i dostępu do jego pól pociąga za sobą pisanie
dużej ilości kodu.

\subsection{Technika EDP}

Rozwinięciem skrótu \emph{EDP} jest \emph{Event Driven Programming}, czyli programowanie zorientowane
zdarzeniowo. Jest to technika programowania, w której przepływ działania aplikacji jest
determinowany przez zdarzenia, np. odczyty sensorów, komunikaty innych programów lub akcje
podejmowane przez użytkownika. Aplikacja w zasadzie dzieli się na dwie części. Pierwsza zajmuje się
aktywowaniem zdarzeń. Druga zajmuję się ich obsługą. Obiekty zajmujące się przechwytywaniem zdarzeń
i reagowaniem na nie nazywane są często \emph{Nasłuchiwaczami} (ang. \emph{Listeners}) lub
\emph{Uchwytami} (ang. \emph{Handlers}).

\emph{EDP} da się z powodzeniem stosować w większości języków programowania. Najłatwiej jednak
osiąga się to w językach, które dostarczają wysoki poziom abstrakcji, np. po przez domknięcia (ang.
closures) albo klasy anonimowe (ang. anonymous classes).

Technika \emph{EDP} jest szeroko wykorzystywana w aplikacjach posiadających bardziej wyrafinowany
graficzny interfejs użytkownika (ang. \emph{Graphical User Interface}, w skrócie \emph{GUI}).

\subsubsection{Wykorzystanie w aplikacjach internetowych}

Językiem stron internetowych jest JavaScript. Elementom języka HTML można podpinać kawałki kodu
w tym języku. Jest to przykład zastosowania techniki \emph{EDP}. Można zauważyć, że w ciągu
ostatnich 10 lat intensywnie wzrasta ilość aplikacji internetowych korzystających z
dobroci JavaScriptu. Związane jest to z metodologią znaną w Internecie pod nazwą \emph{Web 2.0}.

Wykorzystanie JavaScriptu jest o tyle ważne, że ogranicza komunikację przeglądarki WWW użytkownika
z serwerem WWW, na którym aplikacja internetowa jest udostępniona. Zwiększa się wrażenie, że mamy do
czynienia z szybko reagującą na nasze akcje natywną aplikacją biurkową (ang. \emph{Desktop
Application}). Niestety wiąże się to z udostępnieniem kodu z logiką biznesową, co jest polem do
nadużyć i często dziurą w bezpieczeństwie programu.

\subsection{Technologia AJAX}

AJAX oznacza asynchroniczny JavaScript i XML (ang. \emph{Asynchronous JavaScript and XML}).
Technika ta pozwala na komunikację aplikacji internetowej klienckiej z serwerem w sposób
asynchroniczny. Pozwala to na wykonywanie wielu akcji z serwerem, bez potrzeby czekania na
przeładowanie całej strony. Dodatkowo odpowiedź serwera może zmieniać tylko pewną część aplikacji,
podczas gdy reszta pozostaje niezmieniona. AJAX jest jednym z założeń \emph{Web 2.0}.

\subsubsection{Technologie składowe AJAX}

Na technikę tę składa się kilka elementów:

\begin{description}

\item[XMLHttpRequest] jest obiektem umożliwiającym asynchroniczne przesyłanie danych do serwera.
Mimo występowania w nazwie słowa \emph{asynchroniczny}, żądanie to może być także synchroniczne.

\item[JavaScript] jest kluczowym elementem, ponieważ dane odebrane z serwera muszą zostać wstawione
na stronie. Zamiast JavaScriptu można użyć innych języków działających po stronie przeglądarki WWW i
umożliwiających obsługę obiektowego modelu dokumentu (ang. \emph{Document Object Model}, w skrócie
\emph{DOM}), np. JScript lub VBScript. JavaScript jest jednak najlepiej przyjętym i powszechnym
w dzisiejszych czasach rozwiązaniem.

\item[XML] jest użyty jako sposób zapisu informacji wychodzących i przychodzących. W praktyce
możliwym jest użycie zwykłego tekstu, gotowego kodu HTML lub, najczęściej wykorzystywanej,
obiektowej notacji JavaScript (ang. \emph{JavaScript Object Notation}, w skrócie \emph{JSON}).

\end{description}

Powyższe elementy są ściśle związane ze stroną kliencką, czyli przeglądarką WWW. Pozostaje jeszcze
strona serwerowa, która może być napisana w praktycznie dowolnym języku programowania.

\subsubsection{Ograniczenia AJAX}

Jedno z najpoważniejszych ograniczeń technologii AJAX napotykamy kiedy przeglądarka WWW użytkownika
ma wyłączoną opcję przetwarzania JavaScriptu. Jeśli strona nie jest tak zaprojektowana, aby radzić
sobie z tym ograniczeniem, jej funkcjonalność zostaje poważnie ograniczona, ponieważ wszelkie
napisane w JavaScripcie funkcje nie zostaną wykonane.

Powstaje także problem z tradycyjną nawigacją po stronach internetowych (w przód, w tył). Jeśli pod
elementem HTML typu odnośnik zostanie podpięte wywołanie AJAX wywołujące pewną akcję, to naciśnięcie
przycisku \emph{Wstecz} przeglądarki nie przywróci nam strony do jej poprzedniego stanu.

Utrudnione jest także działanie tzw. robotów internetowych (ang. \emph{web crawlers}), ponieważ
nawigacja po naszej stronie może nie przebiegać w tradycyjnym, ogólnie przyjętym stylu.

Oczywiście problemy te da się rozwiązać. Powstają skrypty JavaScript pozwalające na zapamiętywaniu
stanu strony na potrzeby nawigacji (mechanizm taki posiada GWT). Coraz wiecej stron posiada mapy
nawigacyjne (mapy witryny), które są łatwo indeksowalne. Wymaga to jednak czasu na implemetację
odpowiednich rozwiązań.

\subsection{Programowanie komponentowe}

Kolejną ważną techniką stosowaną podczas budowy dużych aplikacji (nie tylko internetowych) jest
programowanie komponentowe. \emph{Komponentem} nazywamy zbiór powiązanych ze sobą funkcji i danych
\cite{comp-szyperski}. Dodatkowo spełnione powinny zostać poniższe kryteria:

\begin{description}

\item[Podstawowa jednostka oprogramowania] W aplikacji komponent jest najmniejszym mechanizmem, z
punktu widzenia funkcjonalności biznesowej.

\item[Kontraktowe interfejsy] Komponent posiada zdefiniowane sposoby wprowadzania i odprowadzania
do niego danych oraz możliwych do wykonania przez niego działań. Określamy to mianem interfejsów
(ang. \emph{Interface}).

\item[Zdefiniowane zależności] Pozwala to na wdrażanie komponentu przez osobę nie posiadającą
wiedzy na temat jego implementacji.

\end{description}

Koncepcja programowania komponentowego nie odbiega znacząco od koncepcji programowania obiektowego.
Przedstawia to tabela \ref{tbl:object-component}.

\begin{table}

\begin{tabular}{|c|c|}
\hline
Programowanie obiektowe & Programowanie komponentowe \\
\hline
Polimorfizm            & Konfiguracja wdrożenia \\
Późne wiązanie wywołań & Późne wiązanie wywołań oraz ładowanie kodu \\
Częściowa hermetyzacja & Pełna hermetyzacja \\
Dziedziczenie klas     & Dziedziczenie interfejsów \\
                       & Powtórne użycie na poziomie binariów \\
\hline
\end{tabular}

\caption{Zestawienie cech programowania obiektowego i komponentowego}
\label{tbl:object-component}
\end{table}

Różnice pomiędzy obiema koncepcjami polegają głównie na silnie wymuszonej hermetyzacji komponentów
oraz na definiowaniu ich abstrakcyjnych interfejsów, które określają sposób komunikacji pomiędzy
nimi.

Programowanie komponentowe nie wnosi nowych atrybutów w stosunku do programowania obiektowego. Po
prostu konsekwentnie i w pełni wykorzystuje cechy obiektowości.

\section{Tworzenie aplikacji RIA w GWT}

W poprzednim podrozdziale zostały opisane najważniejsze wzorce architektoniczne i techniki
programowania, które pozwalają programistom na pisanie spójnych, uporządkowanych oraz łatwo
rozszerzalnych aplikacji internetowych typu \emph{RIA}.

Rozwiązania te można z powodzeniem stosować z większością narzędzi do tworzenia aplikacji
internetowych. W tym miejscu zostanie opisane zastosowanie ich w GWT.

Podejście to zostało wypracowane w ramach analizy nad propozycją rozwoju dużych aplikacji
internetowych wysuniętą przez zespół Google Adwords kierowaną przez Ray'a Ryan'a podczas Google I/O
2009 \cite{mvp-ryan-2009}.

\subsection{Architektura}

Typowa aplikacja pisana z użyciem GWT podzielona jest z reguły na 3 części:

\begin{description}

\item[Klient] Kod w języku Java, który zostanie skompilowany do kodu w języku JavaScript i będzie
uruchamiany w przeglądce WWW użytkownika. Tradycyjnie umieszczany w pakiecie \texttt{client} (np.
\texttt{com.mycompany.myapp.client}).

\item[Wspólna] Kod w języku Java, który zostanie także jak \emph{Klient} skompilowany do
JavaScriptu. Będzie także wykorzystywany po stronie \emph{Serwera}. Przykładem takiego kodu są
obiekty transportowe (ang. \emph{Data Transfer Object}, w skrócie \emph{DTO}). Tradycyjnie kod taki
umieszczany jest w pakiecie \texttt{shared} (np. \texttt{com.mycompany.myapp.shared}).

\item[Serwer] Kod w języku Java, który działa po stronie serwera (kontenera serwletów). Implementuje
interfejsy serwisów znajdujące się w części \emph{Klienta} na potrzeby komunikacji klient-serwer.
Tradycyjnie umieszczany w pakiecie \texttt{server} \\(np. \texttt{com.mycompany.myapp.server}).

\end{description}

Podział ten definiowany jest domyślnie przez standardowy moduł GWT. Istnieje możliwość jego zmiany,
co czasami wydaje się przydatne.

\subsubsection{Zarządcy}

Proponowana architektura w części \emph{Klienta} definiuje pojęcie \emph{Zarządcy} (ang. \emph{Manager}).
Jest to obiekt, który ma za zadanie sterować pewną częścią naszej aplikacji (zarządzać nią).
Najważniejsi zdefiniowani \emph{Zarządcy} to:

\begin{description}

\item[Zarządca Aplikacji (ang. \emph{Application Manager})] Odpowiedzialny jest za tworzenie
instancji \emph{Komponentów} oraz ich rozmieszczenie w układzie interfejsu użytkownina. Posiada także
świadomość o innych \emph{Zarządcach} zdefiniowanych w aplikacji. Można go uznać za \emph{Zarządce}
głównego.

\item[Zarządca Układu (ang. \emph{Layout Manager})] Odpowiedzialny jest za wyznaczenie układu aplikacji
oraz możliwość umieszczania w tym układzie instancji \emph{Komponentów}. Jego implementacja jest
najczęściej zależna od wybranej biblioteki kontrolek (ang. widgets).

\item[Magistrala Zdarzeń (ang. \emph{Event Bus})] Choć nie ma w swojej nazwie słowa "zarządca" jest
jednym z najważniejszych mechanizmów obecnych w tej architekturze. Głównym zadaniem \emph{Magistrali
Zdarzeń} jest umożliwienie spójnej komunikacji pomiędzy \emph{Komponentami}. Daje nam to
hermetyzację i wprowadza uniwersalny interfejs wymiany informacji. Tutaj w głównej mierze
wykorzystywane jest \emph{EDP}.

\item[Zarządca Akcji (ang. \emph{Action Manager})] Zadaniem tego \emph{Zarządcy} jest dostarczenie
\emph{Komponentom} uniwersalnego sposobu przesyłania i odbierania danych ze strony serwera.
Odpowiednia implementacja tego \emph{Zarządcy} umożliwia także przechowywanie (ang. caching)
powtarzających się wyników odpowiedzi części serwerowej.

\end{description}

Istnieje możliwość dodania innych \emph{Zarządców}. Przykładem może być \emph{Zarządca Buforów}
(ang. \emph{Cache Manager}), którego zadaniem może być przechowywanie informacji odebranych z
serwera.

\subsection{Komponent}

Kolejnym pojęciem, które jest definiowane w ramach omawianej architektury to \emph{Komponent}. Jest
to najmniejsza część aplikacji grupująca pewne podobne funkcjonalności. Na \emph{Komponent} składają
się:

\begin{description}

\item[Definicja Modułu (ang. \emph{Module})] Jest to obiekt, w którym przechowywane są instacje
konkretnych funkcjonalności wchodzących w skład \emph{Komponentu}, implementowanych zgodnie ze
wzorcem \emph{MVP}. Utworzenie instancji \emph{Definicji Modułu} powoduje zainicjalizowanie
funkcjonalności. Funkcjonalności te możemy nazywać \emph{Subkomponentami}. Przykładami takich
\emph{Subkomponentu} mogą być: lista użytkowników, szczegóły pojedynczego użytkownika oraz edytor
pojedynczego użytkownika, które zbiorczo stanowią spójny funkcjonalnie i logicznie
\emph{Komponent}.

\item[Fabryka Modułu (ang. Module Factory)] Jest to obiekt odpowiedzialny za tworzenie instancji
\emph{Komponentu}. Korzysta z wzorca \emph{Fabryki}.

\item[Interfejs Wejścia / Wyjścia (ang. \emph{Input / Output Interface})] Jest to zbiór
\emph{Zdarzeń} (ang. \emph{Events}) i ich \emph{Uchwytów} (ang. \emph{Handlers}), który definiuje
sposoby komunikacji wejściowej i wyjściowej \emph{Komponentu}. \emph{Zdarzenia} to obiekty, które są
tworzone przez inne \emph{Komponenty} jako próba komunikacji z \emph{Komponentem} je
udostępniającym. Są przekazywane do \emph{Magistrali Zdarzeń} w celu przekazania ich do
macierzystego \emph{Komponentem}. \emph{Uchwyty} działają po stronie macierzystego \emph{Komponentu} i
reagują na przesyłane przez \emph{Magistrale Zdarzeń} obiekty \emph{Zdarzeń}.

\end{description}

Powyżej opisane zostały elementy wchodzące w skład \emph{Komponentu} po częsci \emph{Klienta}.
Istnieją również składowe wchodzące w skład części \emph{Wspólnej} (\emph{Akcje} i \emph{Wyniki
Akcji}) oraz części \emph{Serwerowej} (głównie \emph{Uchwyty Akcji}). O nich za chwilę.

\subsubsection{Wzorzec MVP}

Przy budowie wcześniej wspomnianych \emph{Subkomponentów} stosowany jest wzorzec \emph{MVP}. Dzięki
jego zastosowaniu dzielimy funkcjonalność na dwie ważne częsci:

\begin{itemize}

\item Definicję zachowania połączoną z logiką biznesową (reprezentowaną przez \emph{Prezenter});
\item Prezentację danych (czyli \emph{Widok}).

\end{itemize}

W naszej architekturze \emph{Widok} to interfejs widoku i jego implementacja. Interfejs
\emph{Widoku} dostarcza metody pobierania i wstawiania danych oraz pozwala na definiowanie
zachowania na poszczególne akcje użytkownika przez \emph{Prezenter}. \emph{Prezenter} używa interfejsu, nie
implementacji \emph{Widoku}. Pozwala to na całkowite rozdzielenie od używanej przez nas konkretnej
biblioteki kontrolek (ang. widgetów) oraz możliwość podmiany implementacji na poziomie
\emph{Definicji Modułu}.

Interfejs \emph{Widoku} powinien definiować następujące metody dostępu:

\begin{itemize}

\item Akcesory pól przechowujących dane. Zgodnie z przyjętą konwencją powinny być to metody typu
setter / getter. Jednak ze względu na chęć rozróżnienia metod dostępu przyjęto następującą formę:

\begin{minted}{java}
interface View {
  // Przyklad akcesorow dla pola 'name'.
  String collectName();
  void displayName(String name);

  // Przyklad akcesorow dla pola 'birthday'.
  Date collectBirthday();
  void displayBirthday(Date birthday);
}
\end{minted}

\item Akcje \emph{Widoku}. Metody te powodują aktywację jakiejś akcji. Przykładem może być walidacja pola
lub zablokowanie możliwość kliknięcia na przycisk:

\begin{minted}{java}
interface View {

  // Akcja walidacji pola 'name'.
  void validateName();

  // Blokowanie mozliwosci podjecia akcji OK.
  void blockOk();
}
\end{minted}

\item Akcesory zachowań. Pozwalają one na wstrzyknięcie definicji zachowania dla jakiejś akcji
\emph{Widoku}. Przykładem może podpinianie zachowania na akcję kliknięcia przycisku:

\begin{minted}{java}
interface View {
  // Ustawienie zachowania dla akcji OK.
  void setOkBehavior(Behavior behavior);
}
\end{minted}

\end{itemize}

Przykładowy \emph{Widok} został zaprezentowany jako Kod \ref{lst:mvp-view}.

\begin{listing}[H]
\inputminted{java}{code/mvp-view.java}
\caption{Przykładowy interfejs \emph{Widoku}}
\label{lst:mvp-view}
\end{listing}

\emph{Prezenter} ma możliwość komunikacji z serwerem, po przez \emph{Zarządce Akcji} oraz
komunikację z innymi \emph{Komponentami} oraz \emph{Subkomponentami}, po przez \emph{Magistrale
Zdarzeń}. Wprowadza i pobiera dane od \emph{Widoku} oraz definiuje jego zachowanie.

Domyślnie \emph{Prezenter} podzielony jest na co najmniej dwie części:

\begin{itemize}

\item Definiowanie zachowania \emph{Widoku}. Polega to na przekazaniu implementacji zachowania.
Przykładem może być wstrzyknięcie kodu, który ma zostać uruchomiony po naciśnięciu przycisku OK:

\begin{minted}{java}
class Presenter extends AbstractPresenter {

  private View view;

  @Override
  protected void initBehavior() {
    // W momencie klikniecia OK.
    view.setOkBehavior(new Behavior() {
      // Zablokuj mozliwosc zapisu.
      view.blockSave();
    });
  }
}
\end{minted}

\item Rejestrowanie \emph{Uchwytów Zdarzeń}. Polega to na dodaniu implemetacji \emph{Uchwytów} dla
zdarzeń przychodzących do \emph{Komponentu}. Przykładem może być reakcja na zamknięcie jakiegoś
innego \emph{Komponentu}.

\begin{minted}{java}
class Presenter extends AbstractPresenter {

  private EventBus eventBus;

  @Override
  protected void initHandlers() {
    eventBus.addHandler(TaskSelectorClosedEvent.TYPE,
      new TaskSelectorClosedHandler() {
      
        @Override
        public void onTaskSelectorClosed(
            TaskSelectorClosedEvent event) {
          // Implementacja reakcji na to zdarzenie.
        }
      }
    );
  }
}
\end{minted}

\end{itemize}

Przykładowy kod \emph{Prezentera} został zaprezentowany jako Kod \ref{lst:mvp-presenter}.

\begin{listing}[H]
\inputminted{java}{code/mvp-presenter.java}
\caption{Przykładowa implementacja \emph{Prezentera}}
\label{lst:mvp-presenter}
\end{listing}

\subsection{Komunikacja z serwerem}

Działanie opisanego wcześniej \emph{Zarządcy Akcji} opiera się na dostarczanym przez GWT mechaniźnie
GWT RPC, które pozwala na definiowanie interfejsów komunikacji zdalnej (ang. remote) po stronie
\emph{Klienta} i implementację ich po stronie \emph{Serwera}. Zasada działania tego mechanizmu jest
oparta o technologię AJAX oraz serializację i deserializację obiektów typu JavaBean do specjalnego
formatu \cite{gwt-rpc}.

\emph{Zarządca Akcji} powstał po to, aby ujednolicić komunikację z serwerem. Nie trzeba dzięki temu
modyfikować ustalonego interfejsu, ale dodawać do części \emph{Wspólnej} nowe \emph{Akcje} (ang.
\emph{Actions}), \emph{Rezultaty Akcji} (ang. \emph{Results}), oraz dla części \emph{Serwera}
\emph{Uchwytów Akcji} (ang. \emph{Action Handlers}).

\begin{listing}[H]
\inputminted{java}{code/dispatch-action-manager.java}
\caption{Interfejs \emph{Zarządcy Akcji}}
\end{listing}

\begin{listing}[H]
\inputminted{java}{code/dispatch-action.java}
\caption{Przykładowa \emph{Akcja}}
\end{listing}

\begin{listing}[H]
\inputminted{java}{code/dispatch-result.java}
\caption{Przykładowy \emph{Wynik Akcji}}
\end{listing}

\begin{listing}[H]
\inputminted{java}{code/dispatch-action-handler.java}
\caption{Przykładowy \emph{Uchwyt Akcji}}
\label{lst:dispatch-action-handler}
\end{listing}

Działanie powyższych obiektów można pokazać w dwóch częściach. Pierwsza dzieje się po
stronie klienta. Tworzona jest instacja \emph{Akcji} oraz jej odpowiedź (ang. callback) związana
ściśle z \emph{Wynikiem Akcji}. Oba obiekty przekazywane są do \emph{Zarządcy Akcji}, który
uruchamia akcję po stronie serwera:

\begin{minted}{java}
// Wywolanie akcji przez zarzadce.
actionManager.execute(
  new LoadInputTypesAction(),
  new AsyncCallback<LoadInputTypesResult>() {

    @Override
    public void onSuccess(LoadInputTypesResult result) {
      // Robimy cos z wynikiem akcji.
      result.getInputTypes();
    }
  }
);
\end{minted}

Część druga dzieje się po stronie serwera. \emph{Akcja} jest przechwytywana przez \emph{Uchwyt
Akcji}, taki jak przedstawiony jako Kod \ref{lst:dispatch-action-handler}. Najważniejsze wywołanie to
zapełnienie \emph{Wyniku Akcji} danymi pobranymi z serwisu biznesowego wstrzykniętego do
\emph{Uchwytu}.

\begin{minted}{java}
@Override
public LoadInputTypesResult execute(LoadInputTypesAction action)
    throws ActionException {
  // Stworzenie wyniku akcji i wypelnienie go danymi.
  return new LoadInputTypesResult(taskService.listInputTypes());
}
\end{minted}

\subsection{Komunikacja pomiędzy komponentami}

\emph{Magistrala Zdarzeń} opiera się o mechanizm, który dostarcza GWT pod postacią klasy
\texttt{com.google.gwt.event.shared.HandlerManager}. Umożliwia ona wcześniej opisywane tworzenie
\emph{Zdarzeń} oraz rejestrację ich \emph{Uchwytów}.

\begin{listing}[H]
\inputminted{java}{code/frame-event-bus.java}
\caption{Interfejs \emph{Magistrali Zdarzeń}}
\label{lst:mvp-event-bus}
\end{listing}

\subsection{Propozycja Google}

Podczas swojego wystąpienia w maju 2009 roku Ray Ryan \cite{mvp-ryan-2009} zaprezentował używaną przez
niego w aplikacji Google Adwords implementację wzorca MVP. Różni się ona od tej zaprezentowanej w
tej pracy.

Różnicą jest definiowanie interfejsów \emph{Widoku}. Propozycja Ray'a Ryan'a opiera
się na tym, że \emph{Widok} nie zwraca surowych danych (stringów, liczb, dat), ale interfejsy do
użytych w implementacji kontrolek (ang. widgetów). Pokazane jest to na przykładowym kodzie.

\begin{listing}[H]
\inputminted{java}{code/mvp-google.java}
\caption{Interfejs \emph{Widoku} - wersja Google}
\label{lst:mvp-gwt}
\end{listing}

\begin{listing}[H]
\inputminted{java}{code/mvp-stogi.java}
\caption{Interfejs \emph{Widoku} - wersja autorska}
\label{lst:mvp-stogi}
\end{listing}

Problem w podejściu zespołu Google Adwords polega na tym, że nie przewidują oni użycia kontrolek
innych niż standardowe GWT. Inne biblioteki kontrolek, takie jak GXT czy SmartGWT, definiują własne
interfejsy dostępu do danych oraz definiowania zachowania kontrolki. Przez to implementacja
\emph{Prezentera} jest uzależniona od wybranej biblioteki kontrolek.

Nie pozwala to na szybką podmianę implementacji. Dodatkowo niektóre kontrolki z podstawowego GWT nie
posiadają zdefiniowanych interfejsów dla ich charakterystycznych akcji. Przykładem może być
kontrolka \\ \texttt{com.google.gwt.user.client.ui.Tree}, której zachowanie na wybranie elementu drzewa
jest zaszyte w implementacji, a nie w dobrze określonym interfejsie.

Wadą podejścia autorskiego jest zwiększona ilość kodu \emph{Widoku}, który trzeba napisać. Każde z
pól danych powinno posiadać swoje akcesory. Każda akcja widoku powinna posiadać swoją metodę. Można
zmniejszyć ilość pisanego kodu generując jakimś narzędziem jego szablony. Wymaga to niestety
dodatkowej pracy. Pozwala jednak na zachowanie większego poziomu abstrakcji i rozdzielenia ról
\emph{Prezentera} i \emph{Widoku}.

\subsection{Nowości w GWT 2.1}

Ray Ryan, dokładnie rok po swoim wystąpieniu w San Francisco \cite{mvp-ryan-2009}, pojawia się ponownie
na konferencji Google I/O, aby zaprezentować koncepcję zmian, które zeszły w GWT od wersji 2.0 do
nadchodzącej wielkimi krokami wersji 2.1. Wystąpienie miało na celu przybliżyć wnioski i
przemyślenia \cite{mvp-ryan-2010} po roku pracy nad dużą aplikacją internetową typu \emph{RIA}.

Poza nowościami związanymi z projektowaniem kontrolek oraz ulepszeń kompilatora GWT, znaczące zmiany
zaszły na polu projektowania samej aplikacji. Podczas prezentacji GWT 2.0 nie została pokazana
implementacja wzorca MVP. Jedynie wskazówki w jaki sposób powinno się ją realizować. GWT 2.1 będzie
dostarczać implementację w postaci dwóch pakietów klas: \texttt{com.google.gwt.app} oraz
\texttt{com.google.gwt.requestfactory}.

\begin{figure}[H]
\centering
\includegraphics[width=1.0\textwidth]{image/pic-gwt-21-arch}
\caption{Nowa propozycja architektury aplikacji GWT}
\end{figure}

Klasy wspomagające do tworzenie komponentów będą zgrupowane jako pakiet\\ \texttt{com.google.gwt.app}.
Będzie dostarczana możliwość generowania modelu transferowego (ang. \emph{Data Transfer Object}, w
skrócie \emph{DTO}), który do tej pory trzeba było pisać samemu. Programiści narzekali, że łamie to
zasadę DRY, czyli "nie powtarzaj się" (ang. Don't Repeat Yourself), ponieważ model transferowy
często przypominał bardzo model biznesowy (encje). Aby uprościć tworzenie typowych kontrolek
(edytory i listy) będzie można korzystać z klas typu \texttt{EditorSupport}. Będzie także możliwość
generowania części \emph{Prezentera}, który teraz zmieni nazwą na \emph{Aktywność} (ang.
\emph{Activity}). Większość możliwości generowania kodu ma dostarczać integracja GWT z narzędziem
Spring Roo, który wspomaga szybkie pisanie aplikacji internetowych w oparciu o Spring Framework.

Także komunikacja części \emph{Klienta} z \emph{Serwerem} ulega uproszczeniom. Ma nią zarządzać
klasa \texttt{RequestFactory} (u \emph{Klienta}) oraz \texttt{RequestFactoryServlet}, czyli
odpowiednik \emph{Zarządcy Akcji} w architekturze autorskiej przedstawionej w tej pracy.

Całość zostanie na pewno dokładnie zaprezentowana po oficjalnym ogłoszeniu wersji 2.1 \footnote{Na czas
pisania pracy dostępna jest wersja 2.1 Milestone 3.}. Budzi to nadzieje na mniejsze ilości powtarzającego
się kodu (ang. boilerplate code). Na dokładne przykłady konkretnej implementacji
i przydatności użycia tych rozwiązań przyjdzie nam jeszcze niestety poczekać.
